ヘッダーをスキップ
Oracle TimesTen In-Memory Databaseオペレーション・ガイド
リリース6.0
B25767-03
  目次へ
目次
索引へ
索引

前へ
前へ
次へ
次へ
 

トランザクションの原子性および永続性

TimesTen Data Managerは、チェックポイント処理とロギングを組み合せて永続性を実現しています(「チェックポイント」および「ログ・ファイル」を参照)。

トランザクションをサポートすると実行時間が長くなるため、TimesTenでは、次のオプションをアプリケーションで選択できます。

概要

次の表に、原子性および永続性のオプションの保証および制限の概要を示します。

ロギング
属性の設定
非ブロッキング・チェックポイント
行レベル・ロック
トランザクションのロールバック
リカバリの手順
消失の可能性があるトランザクション
Logging = 1
Durable
Commits = 1
可能
可能
可能
最新のチェックポイント・イメージの読取り。ログの適用。
障害発生時にコミットされていないトランザクション
Logging = 1
Durable
Commits = 0
可能
可能
可能
最新のチェックポイント・イメージの読取り。ログの適用。
最後のチェックポイント後または永続コミット後にコミットされたトランザクション
Logging = 2
Durable
Commits = 0
不可能
可能
可能
最新のチェックポイント・イメージの読取り。適用するログなし。
最後のチェックポイント後にコミットされたトランザクション
Logging = 0
Durable
Commits = 0
不可能
不可能
不可能
最新のチェックポイント・イメージの読取り。適用するログなし。
最後のチェックポイント後にコミットされたトランザクション

この項の後半では、これらのオプションの詳細について説明します。

トランザクションの原子性および永続性

(Logging=1, DurableCommits=1

デフォルトでは、TimesTenのすべてのトランザクションに永続性があります。トランザクションの結果は維持され、システムに障害が発生した場合でも失われません。

永続性は、チェックポイント処理とロギングの組合せで実装されます(「チェックポイント」および「ログ・ファイル」を参照)。チェックポイント処理では、現在のデータ・ストア・イメージがディスク上のチェックポイント・ファイルに書き込まれ、チェックポイント処理以前にコミットされたすべてのトランザクションの結果に永続性が与えられます。最後のチェックポイント後にコミットされたトランザクションに対しては、従来のロギングによる方法によって永続性が与えられます。トランザクションが処理されるたびに、そのトランザクションによるデータ・ストアの変更内容がインメモリー・ログに記録されます。コミットが行われると、ログ内の該当部分がディスクにフラッシュされます。このログ・フラッシュ処理によって、該当するトランザクションおよび以前コミット済のすべてのトランザクションに永続性が与えられます。

システム障害が発生すると、最新のチェックポイント・イメージがログとともに使用され、トランザクションに一貫性がある最新の状態でデータ・ストアが再構築されます。

デフォルトでは、すべてのTimesTenトランザクションに、永続性のみでなく原子性もあります。トランザクションの結果は、データ・ストアに完全に適用されるか、または完全に適用されないかのいずれかになります。

原子性は、トランザクションがロールバックされた場合、ログを使用してその結果を元に戻すことで実現されます。ロールバックは、ODBC SQLTransact関数またはJDBC Connection.rollbackメソッドを使用するか、または障害発生時にトランザクションがコミットされなかったことによるデータ・ストアのリカバリ中に、アプリケーションによって明示的に発生させることができます。

原子性および永続性を保証するには、アプリケーションでLogging属性およびDurableCommits属性を1(永続データ・ストアの各属性のデフォルト値)に設定する必要があります。

原子性の保証および永続性の遅延

(Logging=1, DurableCommits=0

ロギングを有効にし、永続性の保証は無効にしてデータ・ストアに接続できます。この場合、トランザクションの原子性は保証されますが、永続性は保証されません。このモードは、永続性遅延モードと呼ばれます。

永続性遅延モードでは、永続性保証モードの場合と同様に、トランザクションによってデータ・ストアが変更されるたびに、インメモリー・ログにレコードが書き込まれます。ただし、トランザクションが永続性遅延モードでコミットされると、そのトランザクションはディスクへのログの書込みを待機せず、制御がアプリケーションに戻されます。システム障害が発生するとインメモリー・ログの内容が失われる可能性があるため、このモードでコミットされるトランザクションには永続性がありません。

通常、非永続的にコミットされるトランザクションは、永続コミットが行われるトランザクションよりレスポンス時間が短くなります。これは、トランザクションのコミットにI/Oが不要なためです。非永続的にコミットされるトランザクションには、チェックポイント処理(「チェックポイント」を参照)または後続のトランザクションを永続コミットして永続性を与えることができます。永続性保証モードの場合と同様に、チェックポイント処理を実行すると、チェックポイント処理前にコミットされたすべてのトランザクションに永続性を与えることができます。トランザクションの永続コミットでは、そのトランザクションおよび以前コミット済のすべてのトランザクションがコミットされます。

永続性遅延モードによるパフォーマンス上のメリットを利用し、少数のトランザクションの消失のみ許容できるアプリケーションの場合、バックグラウンドで永続コミットを定期的に実行できます。この場合、最後の永続コミット後に非永続的にコミットしたトランザクションのみ、システム障害が発生すると失われる可能性があります。

アプリケーションで永続性遅延モードをリクエストするには、Logging属性を1(デフォルト)に、DurableCommits属性を0に設定します。このモードでアプリケーションから組込みプロシージャttDurableCommitをコールすると、現行のトランザクションのコミット時に、永続コミットを実行できます。

原子性の保証および永続性の非保証

(Logging=2, DurableCommits=0

TimesTenのディスクレス・ロギング・モードは、永続性遅延モードより優れたパフォーマンスが必要(またはディスクへのアクセス権がない)で、トランザクションの消失の可能性が高くても許容可能なアプリケーションで使用できます。

ディスクレス・ロギング・モード(永続性非保証モード)では、インメモリー・ログはディスクに書き込まれません。このため、ログを使用してトランザクションの永続性を保証することはできません。このモードでのログは、トランザクションのロールバックでトランザクションの原子性を確保する目的にのみ使用されます。永続性非保証モードでトランザクションに永続性を与える方法は、データ・ストアをチェックポイント処理する方法のみです(「チェックポイント」を参照)。

システム障害が発生すると、他のモードの場合と同様に、リカバリによって最後のチェックポイント・イメージからデータ・ストアがリロードされます。ただし、ディスク上にログがないため、最後のチェックポイント後にコミットされたすべてのトランザクションの結果は失われます。

ディスクレス・ロギングには多くの制限があるため、注意して使用する必要があります。

注意: 行レベル・ロックが有効になっている場合は、ディスクへのロギングを選択することを強くお薦めします(『Oracle TimesTen In-Memory Database APIおよびSQLリファレンス・ガイド』のロック・レベルに関する項およびロギングに関する項を参照)。ディスクレス・ロギングは、ディスクのないシステム、またはディスクへの書込みが頻繁に行われない場合でもパフォーマンスに大きく影響を及ぼす比較的ディスク性能の低いシステム用に提供されています。ディスクレス・ロギングを有効にすると、ログ・レコードは内部ログ・バッファにのみ保存されます。ログ・バッファはディスクに書き込まれません。トランザクションがアクティブな間に内部ログ・バッファ内の領域がなくなると、ログ・バッファが一杯になったトランザクションはTimesTenによって強制終了されます。ディスクレス・ロギングを有効にしてアプリケーションを実行すると、一部のトランザクションが断続的に強制終了される場合があります。

原子性および永続性の非保証

(Logging=0, DurableCommits=0

レスポンス時間を最小にするために、アプリケーションですべてのロギングを無効にできます。ただし、これによって、永続性および原子性の両方が失われる危険があります。このため、非ロギング・モードは、注意して使用する必要があります(『Oracle TimesTen In-Memory Database APIおよびSQLリファレンス・ガイド』のロギングに関する項を参照)。

ディスクレス・ロギング・モードの場合と同様に、ロギングが無効になっている場合にトランザクションの永続性を確保する方法は、データ・ストアに対してチェックポイント処理を実行する方法のみです。このため、システム障害が発生すると、最後のチェックポイント後にコミットしたすべてのトランザクションが失われます。また、ロギングを有効にすると原子的に失敗する処理は、ロギングを無効にすると非原子的に失敗します。たとえば、SQL UPDATE文で1行以上の行を更新した後にエラーが発生した場合、更新済の行の内容はリストアされません。このような状況が発生すると、処理が非原子的に失敗したことを示す警告が戻されます。

ロギングが無効になっている場合は、トランザクションによるデータ・ストアへの変更のログがないため、トランザクションをロールバックすることはできません。したがって、すべてのトランザクションをコミットする必要があります。非ロギング・モードでトランザクションをロールバックしようとすると、エラーが発生します。ロギングが無効になっているときは、行レベル・ロックも無効になっています。アプリケーションでは、データ・ストア・レベル・ロックを使用する必要があります。

非ロギング・モードには多くの制限があるため、エラー発生時に再開が可能な用途(新しいデータ・ストアへのデータのロードなど)でのみ使用する必要があります。これ以外の用途で使用すると、コミットされていないデータが保持され、一貫性がなくなる場合があります。

非ロギング・モードを使用するには、アプリケーションでLogging=0を設定する必要があります。また、他の属性(LockLevel=1、DurableCommits=0およびLogPurge=0)も設定する必要があります。